% Generated by roxygen2: do not edit by hand
% Please edit documentation in R/getblocksnearbyviaQuadTree.R
\name{getblocksnearbyviaQuadTree}
\alias{getblocksnearbyviaQuadTree}
\title{Fast way to find nearby points (distance to each Census block centroid near each site)}
\usage{
getblocksnearbyviaQuadTree(
  sitepoints,
  radius = 3,
  radius_donut_lower_edge = 0,
  maxradius = 31.07,
  avoidorphans = FALSE,
  report_progress_every_n = 500,
  quiet = FALSE,
  use_unadjusted_distance = FALSE,
  retain_unadjusted_distance = TRUE,
  quadtree,
  updateProgress = NULL
)
}
\arguments{
\item{sitepoints}{data.table with columns lat, lon giving point locations of sites or facilities around which are circular buffers}

\item{radius}{in miles, defining circular buffer around a site point}

\item{radius_donut_lower_edge}{radius of lower edge of ring if analyzing ring not full circle}

\item{maxradius}{miles distance (max distance to check if not even 1 block point is within radius)}

\item{avoidorphans}{logical If TRUE, then where not even 1 BLOCK internal point is within radius of a SITE,
it keeps looking past radius, up to maxradius, to find nearest 1 BLOCK.
What EJScreen does in that case is report NA, right? So,
does EJAM really need to report stats on residents presumed to be within radius,
if no block centroid is within radius?
Best estimate might be to report indicators from nearest block centroid which is
probably almost always the one your site is sitting inside of,
but ideally would adjust total count to be a fraction of blockwt based on
what is area of circular buffer as fraction of area of block it is apparently inside of.
Setting this to TRUE can produce unexpected results, which will not match EJScreen numbers.

Note that if creating a proximity score, by contrast, you instead want to find nearest 1 SITE if none within radius of this BLOCK.}

\item{report_progress_every_n}{Reports progress to console after every n points,
mostly for testing, but a progress bar feature might be useful unless this is super fast.}

\item{quiet}{Optional. set to TRUE to avoid message about using getblock_diagnostics(),
which is relevant only if a user saved the output of this function.}

\item{use_unadjusted_distance}{logical, whether to find points within unadjusted distance}

\item{retain_unadjusted_distance}{set to FALSE to drop it and save memory/storage. If TRUE,
the distance_unadjusted column will save the actual distance of site to block internal point
-- the distance column always represents distance to average resident in the block, which is
estimated by adjusting the site to block distance in cases where it is small relative to the
size of the block, to put a lower limit on it, which can result in a large estimate of distance
if the block is very large. See EJScreen documentation.}

\item{quadtree}{(a pointer to the large quadtree object)
created using indexblocks() which uses the SearchTree package.
Takes about 2-5 seconds to create this each time it is needed.
It can be automatically created when the package is attached via the .onAttach() function}

\item{updateProgress, }{optional function to update Shiny progress bar}
}
\description{
This is what \code{\link[=getblocksnearby]{getblocksnearby()}} uses to do the work.
Given a set of points and a specified radius in miles,
this function quickly finds all the US Census blocks near each point.
This does the work actually supporting getblocksnearby()
}
\details{
For each point, it uses the specified search radius and finds the distance to
every block within the circle defined by the radius.
Each block is defined by its Census-provided internal point, by latitude and longitude.

Results are the sites2blocks table that would be used by doaggregate(),
with distance in miles as one output column of data.table.
Adjusts distance to avg resident in block when it is very small relative to block size,
the same way EJScreen adjusts distances in creating proximity scores.

Each point can be the location of a regulated facility or other type of site, and
the blocks are a high-resolution source of information about where
residents live.

Finding which blocks have their internal points in a circle provides
a way to quickly estimate what fraction of a block group is
inside the circular buffer more accurately and more quickly than
areal apportionment of block groups would provide.
}
\examples{
  # indexblocks() # if localtree not available yet, quadtree = localtree
  x = getblocksnearby(testpoints_1000, radius = 3)
}
\seealso{
\code{\link[=ejamit]{ejamit()}} \code{\link[=getblocksnearby]{getblocksnearby()}}
}
\keyword{internal}
